Summary

Adds ChaCha20-Poly1305 (AEAD-4) encryption alongside the existing AES-128-ECB + HMAC-2 scheme. Updated nodes send AEAD-4 to peers that advertise support and fall back to ECB for legacy peers. All nodes can decode both formats. Old nodes continue to work unchanged.

Nonces are persisted to flash so they survive reboots without risk of reuse.

Relates to #259.

What This Means in Practical Terms

The current encryption has a few weaknesses that this PR addresses:

• Message tampering is too easy to attempt. The existing 2-byte authentication code means an attacker only needs about 65,000 guesses to forge a valid-looking message. At LoRa speeds that's roughly 9 hours of continuous attempts. The new 4-byte tag raises this to over 4 billion guesses — at LoRa rates, that would take over a century.

• Identical messages look identical on the air. The current block cipher (ECB mode) produces the same ciphertext for the same plaintext, which can reveal patterns — for example, you could tell when someone sends the same message twice. The new scheme produces completely different ciphertext every time, even for identical messages.

• Addressing fields are now protected. Currently, only the message body is authenticated. With AEAD, the payload type and addressing hashes (which identify sender and recipient) are included in the authentication check, so an attacker cannot swap or modify them without detection. Outer routing fields like TTL and hop path are intentionally left unauthenticated so repeaters can still forward packets through the mesh.

• Messages get slightly smaller. ECB pads every message up to a 16-byte boundary, wasting airtime. The new scheme has no padding, so most messages shrink by a few bytes on the wire.

• Nothing breaks. Updated nodes send AEAD-4 to peers that advertise support, and fall back to ECB for legacy peers. Old nodes are completely unaffected — they never receive AEAD-4 messages because the sender checks their capability first.

• Nodes advertise their capabilities. Updated nodes include a flag in their advertisements saying "I understand the new encryption." When two updated nodes discover each other, they automatically start using AEAD-4 for their communication.

• Nonces survive reboots. Per-peer nonce counters are saved to flash periodically and before clean reboots. After a dirty reset (power loss, watchdog, brownout), nonces are bumped forward by a safety margin to guarantee no reuse.

Wire Format

Current ECB:

[HMAC:2] [ECB_ciphertext:N×16]     (padded to block boundary)

New AEAD-4 (same position in payload):

[nonce:2] [ciphertext:M] [tag:4]    (exact plaintext length, no padding)

Average overhead: ~6 bytes (AEAD) vs ~9.5 bytes (ECB). Most messages get smaller.

Cryptographic Design

Per-message key derivation (eliminates nonce-reuse catastrophe):

msg_key[32] = HMAC-SHA256(shared_secret, nonce || dest_hash || src_hash)

Including dest_hash || src_hash makes keys direction-dependent — Alice→Bob and Bob→Alice derive different keys even with the same nonce value (for 255/256 peer pairs; the 1/256 where dest_hash == src_hash is a residual limitation of 1-byte hashes).

IV construction (12 bytes, from on-wire fields):

iv[12] = { nonce_hi, nonce_lo, dest_hash, src_hash, 0, 0, 0, 0, 0, 0, 0, 0 }

Associated data (authenticated but not encrypted):

• Peer messages: header || dest_hash || src_hash
• Anonymous requests: header || dest_hash
• Group messages: header || channel_hash

Route type bits are masked out of the header in associated data (header & ~PH_ROUTE_MASK), since routing mode changes per hop as repeaters forward packets.

Nonce management: 16-bit counter per peer, persisted to flash. See "Nonce Persistence" section below.

Nonce Persistence

Nonces are persisted to a dedicated file on flash (/nonces for companion radios, /s_nonces for server firmware).

Periodic saves: After every NONCE_PERSIST_INTERVAL (50) messages to a given peer, the nonce file is written. A dirty flag tracks whether any nonce has advanced since the last save.

Clean reboot: Software restarts and deep sleep wakes load the persisted nonces as-is. A onBeforeReboot() callback in CommonCLI flushes any dirty nonces before the restart.

Dirty reboot: Power-on, watchdog, and brownout resets are detected via wasDirtyReset() (platform-specific: esp_reset_reason() on ESP32, RESETREAS register on NRF52). After a dirty reset, all loaded nonces are bumped forward by NONCE_BOOT_BUMP (100), which is at least 2× the persist interval, guaranteeing that even the worst-case unpersisted nonce is safely skipped.

Format: Simple array of {pub_key_prefix[6], nonce[2]} entries, matched to in-memory contacts/clients on load.

Security Comparison

Scope

All node types (companion radio, repeater, room server, sensor) support both AEAD-4 decode and AEAD-4 send for peer messages.

Group Message Considerations

Group channels share a single key among all members. With a 2-byte nonce and multiple senders, cross-sender nonce collisions follow the birthday bound (~300 messages for 50% probability on an active channel). A collision leaks P1 ⊕ P2 for that specific message pair via crib-dragging, but:

• No key recovery — per-message key derivation via HMAC-SHA256 is one-way
• No cascade — each collision is isolated, doesn't affect other messages
• Bounded threat model — the attacker must not have the channel PSK (if they do, they can already read everything)

This is mainly beneficial for public/hashtag channels where the PSK is already widely known and the ECB pattern leakage and weak MAC are a greater concern than the bounded nonce collision risk.

Potential future mitigations explored and deferred:

• Per-sender derived keys (HMAC(channel_secret, sender_pub_key)) — eliminates cross-sender collisions but requires receivers to know all senders' public keys, changing the group security model from "know the PSK = full access" to "know the PSK + sender discovery = access." Ruled out as a usability regression.
• Expanded nonce (4 bytes instead of 2) — pushes birthday bound to ~65,000 messages (~2 years at 100 msgs/day). Costs 2 extra bytes of airtime and creates a different wire format for groups vs peers.
• Sender hash byte on wire — differentiates senders for key derivation at 1 byte cost, but leaks sender identity metadata (traffic correlation, identification via adverts) that is currently hidden inside the encrypted payload.

Decode Order

Adaptive per-peer: for peers with CONTACT_FLAG_AEAD set, try AEAD-4 first then ECB fallback. For unknown/legacy peers, try ECB first then AEAD-4 fallback. This avoids the 1/65536 ECB false-positive rate on AEAD packets (nonce bytes matching truncated HMAC) for known AEAD peers, while minimizing wasted CPU for legacy peers.

Capability Advertisement

• feat1 bit 0 (FEAT1_AEAD_SUPPORT) is set in adverts for all node types (chat, repeater, room, sensor)
• Receivers record peer capability in ContactInfo.flags bit 1 (CONTACT_FLAG_AEAD)
• Old nodes parse feat1 but ignore the value (forward-compatible via existing AdvertDataParser)

Files Changed

• src/MeshCore.h — AEAD constants (AEAD_TAG_SIZE, AEAD_NONCE_SIZE, CONTACT_FLAG_AEAD, FEAT1_AEAD_SUPPORT, NONCE_PERSIST_INTERVAL, NONCE_BOOT_BUMP)
• src/Utils.h / src/Utils.cpp — aeadEncrypt() and aeadDecrypt() using ChaChaPoly
• src/Mesh.h — getPeerFlags(), getPeerNextAeadNonce() virtuals; aead_nonce param on createDatagram/createPathReturn
• src/Mesh.cpp — AEAD send path in createDatagram/createPathReturn; adaptive try-both decode order per peer
• src/helpers/ContactInfo.h — uint16_t aead_nonce field, nextAeadNonce() helper
• src/helpers/BaseChatMesh.h / BaseChatMesh.cpp — Advertise AEAD, track peer capability, AEAD send for all peer message types, nonce persistence (dirty tracking, periodic save, load with boot bump)
• src/helpers/ClientACL.h / ClientACL.cpp — Server-side AEAD nonce tracking and persistence for repeater/room/sensor clients
• src/helpers/CommonCLI.h / CommonCLI.cpp — Advertise AEAD for repeaters/rooms/sensors; onBeforeReboot() callback for nonce flush
• src/helpers/ArduinoHelpers.h — wasDirtyReset() helper (ESP32/NRF52 reset reason detection)
• examples/companion_radio/DataStore.h / DataStore.cpp — Nonce file I/O for companion radio
• examples/companion_radio/MyMesh.h / MyMesh.cpp — Wire up nonce persistence and reboot callback
• examples/simple_repeater/MyMesh.h / MyMesh.cpp — AEAD send support and nonce persistence
• examples/simple_room_server/MyMesh.h / MyMesh.cpp — AEAD send support and nonce persistence
• examples/simple_sensor/SensorMesh.h / SensorMesh.cpp — AEAD send support and nonce persistence

Build Verification

• ESP32 (Heltec_v3_companion_radio_ble): builds successfully
• NRF52 (Xiao_nrf52_companion_radio_ble): builds successfully

Future Work

• Group messages: send AEAD-4 (all updated nodes can already decode it)
• ANON_REQ: remain ECB (no prior capability exchange possible)